Dear Mirja, 

Thanks very much for your review and comments. Please find the reply inline: 

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The following text in section 4 seems to indicate that scheduling is done
> on a per-packet basis:
> "When there is a
>   datagram to be sent to a destination, the source router acquires a
>   path from the Multi-path Routing Set (MAY be Round-Robin, or other
>   scheduling algorithms)."
> This seems not appropriate as e.g. TCP packets routed on links with
> largely different delays may suffer performance. ECMP usually hashes the
> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and routes
> all packets belonging to the same flow on the same route. I recommend to
> apply the same here.
> 
> Also related is this text in section 8.4 that should explain Round-Robin
> on a per flow basis instead. Further this should only be an example
> scheduling alogirthm while text belong seems to assume that Round-Robin
> is always used.
> "If a matching Multi-path Routing Tuple is obtained, the Path Tuples
>   of the Multi-path Routing Tuple are applied to the datagrams using
>   Round-robin scheduling.  For example, there are 2 path Tuples
>   (Path-1, Path-2) for destination router D. A series of datagrams
>   (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D.
>   Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 for
>   Packet 3, etc.  Other path scheduling mechanisms are also possible
>   and will not impact the interoperability of different
>   implementations.”

In fact, the per-packet scheduling is an intentional choice because:

1. The aimed scenario is mobile ad hoc networks, which have high packet loss by nature. One of the most important reasons is route failure due to mobility — in such case, if a per-flow scheduling is applied, the whole flow will lost. On the other hand, if we send the packets in disjoint paths (not necessarily equal cost), we can still make use partial information of the flow, or even reconstruct the flow with erasure coding. This is especially interesting for video/audio streaming. 

2. In such kind of lossy networks, the traditional TCP performs very poor [1]. So as far as I know, TCP is not very popular in ad hoc networks. On the other hand, based on our study, the multi-path routing can actually reduce the overall jitter [2]. 

We understand your concern on this issue (and you can imagine that you are not the first one who raises this ;). It is also something that we want to have further experience from this *experimental* draft, as we stated in the “experiments to be conducted” section:

	• Different path-selection schedulers. By default, round-robin scheduling is used to select a path to be used for datagrams. In some scenarios, weighted scheduling can be considered: for example, the paths with lower metrics (i.e., higher quality) can transfer more datagrams compared to paths with higher metrics. 
	• The impacts of the delay variation due to multipath routing. [RFC2991] brings out some concerns of multipath routing, especially variable latencies. Although current experiment results show that multipath routing can reduce the jitter in dynamic scenarios, some transport protocols or applications may be sensitive to the datagram re-ordering. 
	• The disjoint multipath protocol has interesting application with erasure coding, especially for services like video/audio streaming [WPMC11]. The combination of erasure coding mechanisms and this extension is thus encouraged.


[1] Performance Evaluation of TCP over Mobile Ad-hoc Networks https://arxiv.org/pdf/1002.2189.pdf <networkshttps://arxiv.org/pdf/1002.2189.pdf> 
[2] Multipath optimized link state routing for mobile ad hoc networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, 2011.

> 
> Related is this text in section 8.4.:
> "If datagrams without source routing header need to be forwarded using
>   multiple paths (for example, based on the information of DiffServ
>   Code Point [RFC2474])"
> RFC2474 does not specify any application requirements on multipath use
> and as such the DiffServe field should not be used to determine if the
> flow can be routed on multiple paths. The ability to profit from
> multipath routing depends not only on the application and protocols used
> but also on the characteristics of the multipath link(s); so it's hard to
> make any implicit assumptions here. However, if routing would only be
> recommended on a per-flow basis this problem does not occur and the
> brackets above could be remove. Further, if routed on a per flow basis
> would be done, DiffServ could actually be used to decide which path to
> use, if e.g. one path has a lower delay, but that seem to need further
> discussion as well.

As we mentioned before, the multipath routing has special interests in audio/video streaming applications. For applications that requires strict ordering, single path can be used. For streaming and time-critical applications, the multi-path application might be more interesting, which can be identified by the DiffServe information. 

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Minor comments/questions:
> 
> 1) section 8.4: this sentence is not clear:
> "It is RECOMMENDED to use MTU sizes considering the source routing
>   header to avoid fragmentation."
> MAYBE
> "It is NOT RECOMMENDED to fragment the IP packet if the packet with the
> source routing header would  exceed the minimum MTU along the path. In
> this case source routing and therefore the additional path calculated by
> MP-OLSRv2 SHOULD NOT be used.”

Fixed. 

> 
> 2) section 9:
> "For IPv6 networks, it MUST
>      be set to 0, i.e., no constraint on maximum number of hops."
> Why is that?

Because the current RFC6554 supports only IPv6 strict source routing, we thus need to keep all the path information in the source routing header, in which case we don’t know the number of hops. 

On the other hand, we noticed that the IPv6 segment routing header is being discussed at 6man, we thus have the following text in the “Experiments to be conducted” section:

	• Use of IPv6 loose source routing. In the current specification, only strict source routing is used for IPv6 based on [RFC6554]. In [I‑D.ietf‑6man‑segment‑routing‑header], the use of loose source routing is also proposed in IPv6. In scenarios where the length of the source routing header is critical, the loose source routing can be considered.

> 
> 3) Not sure why section 12.1. is there? Can this be removed?

Removed. 

Agains, we appreciate your valuable comments and hope that our reply addresses your concern. 

regards

Jiazi

> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet